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METHOD AND DEVICE FOR THE STIMULATION OF FUNCTIONS 
FOR CONTROLLING OPERATING SEQUENCE 



Field Of The Invention 

The present invention is directed to a method and a device for the stimulation of functions for 
controlling operating sequences, in particular in a motor vehicle. The present invention is also 
directed to a corresponding control unit and a corresponding computer for function 
5 stimulation and the associated computer program as well as the corresponding computer 
program product. 

Background Information 

In function development of control unit sofhvare, in particular in automotive control imits for 
controlling the engine, brakes, transmission, etc., the bypass application is a rapid prototyping 
10 method for developing and testing new control unit functions. However, such development of 
functions is also possible with all other control unit applications, e.g., in the field of 
automation and machine tools. 

Two applications of extemal control unit bypass, as described in German Published Patent 
Application No. 101 06 504, for example, and internal control unit bypass applications, as 
1 5 described in German Published Patent Application No. 102 28 610, for example, may be used 
as development methods here. 

German Published Patent Application No. 101 06 504 describes a method and an emulation 
device for emulating control functions and/or regulating functions of a control unit or a 
regulating unit of a motor vehicle in particular. For emulation, the functions are transferred to 

20 an extemal emulation computer, a data link being established via a software interface of the 
emulation computer and a software interface of the control unit/regulating unit before the 
start of emulation. To greatly accelerate the development and programming of new 
control/regulating functions of the control unit/regulating unit, it is proposed that the software 
interfaces should be configured for emulation of different control/regulating functions before 

25 the start of emulation without any change in software. 
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German Published Patent Application No. 102 28 610 describes a method and a device for 
testing a control program by using at least one bypass fiinction in which the control program 
is executed together with the at least one bypass function on an electric computing unit. The 
bypass functions are coupled to preselected interfaces via dynamic links. 

Independently of these two methods and devices, interventions in the control unit software 
are necessary for applicability. Such interventions are referred to with the term bypass 
breakpoint or software breakpoint. A bypass breakpoint, i.e., software breakpoint, describes 
exactly the location in a software function where the content of a control unit variable is not 
described by the software program but instead is described via detours, e.g., via a bypass 
software function. Software breakpoints are highly individual and in the normal case are not 
part of a control unit software program because memory resources are used for this. 

If a function developer requires a control imit program having software breakpoints, these are 
incorporated into a program version only after the development department has been 
commissioned. For this purpose, the software development manually modifies the source 
15 code of the corresponding function and, by running a compiler and link, creates a new control 
unit program which is used explicitly for the prototyping application. 

The disadvantage of this method and/or the device as explained in the related art includes the 
long running time until availability of the rapid prototyping program version. An important 
factor here is the high technical and administrative cost for the specification and 
20 implementation of the software interventions. 

According to the information currently available, a comparable method is based on the idea 
of replacing only the store instructions (write access to a control unit variable) via jump 
instructions to a subfunction. However, in microcontrollers having a mixed instruction set 
(16/32-bit CPU instmctions), the store instructions may already be 16 bits because addressing 
is performed indirectly via address registers. These 16-bit instructions cannot be used to call a 
subfunction because a direct address-oriented call of a subfunction requires a 32-bit jump 
instruction. Therefore, the method according to the related art is usable only to a limited 
extent and may be used only with microprocessors having a strict 32-bit instruction set. In 
other words, when the store instruction has a fixed bit width, flexibility with regard to the 
function development is greatly restricted here. This is also true when a certain store 
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instruction must not be manipulated at all for other reasons, so that populating in this way via 
a jump instruction to a subfunction is then not possible at all. 

In function development for control unit software as mentioned above, testing of software 
fimctions is performed on laboratory vehicles (measurement sites) or via appropriate software 
5 testing environments (module test). When performing tests on laboratory vehicles, the control 
unit inputs are stimulated fi"om the outside by electric signals to thereby observe and measure 
the corresponding responses of the control unit and the software. In the case of the available 
software test environments for the module tests, only the software ftmctions to be 
investigated are considered in a stand-alone operation within the test environment without 
10 taking into accoimt feedback effects or cross-coupling with the system as a whole. 

Summary Of The Invention 

The object of the present invention is to stimulate software ftmctions in an integrated state 
within a software program in runtime and to test them and thus overcome the aforementioned 
problems in the related art. 

15 The present invention is directed to a device and a method for the stimulation of fijnctions for 
controlling operating sequences, where the ftmctions access at least one global variable of at 
least one program for control, at least one stimulation fimction which accesses the at least one 
global variable via at least one software breakpoint being advantageously provided. 

The fimctions are expediently stimulated within the program during the runtime of the 
20 program, in particular in real time within a runtime system. 

It is advantageous here that the global variable is assigned a first piece of data information 
and this first piece of data information is replaced by a second piece of data information 
corresponding to the new stimulation values. 

It is preferably within the scope of the present invention for the stimulation of functions to be 
25 accomplished by an internal bypass, with the software breakpoint being accomplished by 
assigning address information to the global variable, the address information being loaded 
fi'om a memory means by a load instmction and the address information of the global 
variable of the load instruction being replaced. 
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The address information of the global variably is advantageously replaced by the address 
information of a pointer variable, an initial address of the function being determined from the 
address information, and the functions for control of operating sequences being replaced by 
replacing the address information with additional functions. 

5 The software breakpoint may also expediently be accomplished by having the global variable 
addressed by a store instruction and the store instruction manipulated onto the global variable 
by replacing the store instruction with a jimip instruction and replacing the functions for 
control of the operating sequences with additional functions by replacing the store instruction 
with the jump instruction. 

10 The present invention expediently uses "dynamic hooks" of software breakpoints without any 
changes in source code. The methods described for accomplishing this modify the address 
information of load instmctions, modify the function calls and insert new program codes. 
These modifications are performed on an existing software program version, e.g., on the basis 
of targeted HEX code modifications. 

15 It is also advantageous that the address information of the global variable is replaced by the 
address information of a pointer variable, the address information of the pointer variable 
being in a reserved memory area, in particular of the memory means in the control unit. 

In addition to the modification with respect to the load instructions, in one embodiment a 
store instruction is advantageously manipulated onto the global variable by replacing the 
20 store instruction with a jimip instruction. The functions for control of the operating sequences 
are expediently replaced and/or expanded by replacing the store instruction with the jump 
instruction through additional functions. 

According to the aforementioned device and method, the present invention describes a 
control unit containing such a device and makes it the object of the present invention along 

25 with a computer program suitable for execution of such a method. This computer program is 
executed on a computer, in particular an application control unit system according to the 
present invention or an application PC. The computer program according to the present 
invention may be stored on any machine-readable mediimi. Such a computer-readable data 
medixmi or machine-readable medivun may be in particular a diskette, a CD-ROM, a DVD, a 

30 memory stick or any other portable memory medium. Likewise, memory media such as 

ROM, PROM, EPROM, EEPROM or flash memories and volatile RAM memories, etc., are 
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also possible for storage. The choice of memory medium, i.e., the machine-readable medium, 
is thus not to be regarded as restrictive with respect to the computer program product as the 
object of the present invention. 

Using the present invention, the various rapid prototyping methods, software test methods 
5 and data calibration methods are rendered more rapidly usable and more flexible in handling. 
Thus the software breakpoints are used without tying up software development capacity. This 
results in a lower technical and administrative complexity on the whole and therefore reduces 
costs. At the same time, microprocessor types having a mixed instruction set of 16/32-bit 
CPU instructions, for example, may be supported. 

10 When activating the test sequences, the control unit fimction to be investigated is 

advantageously stimulated automatically by the integrated test software within the runtime 
system. 

The advantages of the object according to the present invention also include the fact that for 
the stimulation of the control unit fimction, no electric signals need be applied to the control 
15 imit fi-om the outside. Another advantage is that the calculated output values of the stimulated 
control imit fimction are directly available again to the real time system. Thus, for example, 
complex control algorithms within the control unit may be investigated and tested in greater 
detail and developed fiirther if necessary. 

Brief Description Of The Drawings 
20 Figure 1 shows a system or a device according to the present invention for adapting the 
fimctions. 

Figure 2 illustrates the sequence for determining the breakpoints or software breakpoints in 
the program. 

Figure 3 shows an overview and a selection of various methods for modification of the load 
25 instructions and/or the store instructions. 

Figure 4 shows a program diagram for a first and preferred modification method of the load 
instruction. 

Figure 5 illustrates a program diagram for a second modification method of the store 
instruction. 
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Figure 6 illustrates a program diagram for a third modification method of the store 
instmction. 

Figure 7 illustrates a program diagram for a fourth modification method of the store 
instruction. 

5 Figure 8 shows a schematic diagram for adjusting the calls of the Amotions for controlling the 
operating sequences. 

Figure 9 shows the hook fimction for tying in the additional functions. 

Figure 10 shows a schematic diagram of the memory segments in the memory means with 
regard to the hook fimction. 

10 Figure 1 1 shows in greater detail a complete development process according to the present 
invention. 

Figure 12 shows the internal bypass, in particular the procedure of dynamic linking. 
Figure 13 illustrates a basic diagram for the stimulation of fimctions. 
Figure 14 shows a flow chart for creating the test sequence software. 
15 Figure 15 shows the development process according to the present invention. 
Detailed Description 

Figure 1 shows a schematic diagram of an application arrangement having a control xmit 100 
and an application system 101, which are connected to interfaces 103 and 104 via a link 102. 
This link 102 may be designed to be wired or wireless. A microprocessor 105 is shown in 

20 particular having a mixed instruction set. Memory means 106 includes an address register 
108, a data register 107 and a memory area for the at least one program to be adapted with 
regard to fimctions. The control means for implementing the present invention may be 
contained in the application system and/or represented by it or designed using the 
microprocessor itself. Likewise, memory means for implementation of the present invention 

25 may also be situated outside the control unit, in particular in the application system. The 
object according to the present invention is implementable using the device shown here. 
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Although the functions may be adapted using .an external bypass, the advantageous 
embodiment is to perfomi the adaptations internally in such a way that they are tied into the 
program run and therefore there are dynamic hooks for software interventions without any 
source code changes. 

5 The object described here modifies the address information of load instructions, modifies the 
content of store instructions, modifies the address information of function calls and adds new 
program codes. These changes are implemented here in the exemplary embodiment on an 
existing software program version on the basis of specific hex code modifications. 

The various components with regard to the object "dynamic software breakpoint" according 
10 to the present invention being explained below are: 

• Determination of the program points 

• Modification of the program points including 

modification of the load/store instructions and 
modification of the function calls 
15 • Creation of additional program code 

• Tying in the software breakpoint code 

• Segmenting the memory areas and 

• Development process for creation of the program code 

• Intemal bypass 

20 • Software test through the stimulation of functions. 



The method described below is based on the use of microcontrollers having a mixed 
instmction set, in particular 16/32-bit CPU instructions. For example, the TriCore TC17xx 
microcontroller (RISC/DSP/CPU) from Infineon is the example used here; it is a component 
25 of a control unit for controlling operating sequences, in particular in a motor vehicle, e.g., for 
engine control or for controlling the steering, transmission, brakes, etc. 

However, this method may also be used with microprocessors having a non-mixed instruction 
set, in particular in pure 32-bit microprocessors (RISC processors, e.g., PowerPC/MPCSxx). 

Essentially in this method it is assimied that the code generator of the compiler arranges the 
30 machine instructions sequentially. This is understood to refer to the sequential arrangement of 
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instructions for loading address information of an indirectly addressed control unit variable, 
for example, into the corresponding address registers. In contrast, in the case of a directly 
addressed variable, the address information is in the instruction itself. This is the case with 
most compilers. 

5 Determination of the program points (Figure 2) 

The starting point for this is a control xmit software program which is available in the form of 
a hex code file, for example. Additional files may include a data description file (e.g., ASAP) 
and a linker file (e.g., ELF binary) which supply information about control imit variables and 
control unit fimctions. 

10 Using a disassembler software program (e.g., a Windows software program), the hex code 

file is disassembled. The corresponding addresses of the control unit variables to be bypassed 
are taken firom the data description file or from a reference databank created for the method. 

The disassembler program created according to the present invention, e.g., a Windows 
software program, seeks the corresponding access instructions to the control xmit variables 
15 (load/store instructions) in the disassembled program code with the assistance of the address 
information of these variables being sought, which affect the content of the variables. 

This disassembler program as a Windows software program is a simulation program which 
checks the register contents after each assembler instruction. If a store instruction is localized 
and the content of the loaded address register corresponds to the address value of the control 
20 unit being sought or if the memory destination of the store instruction corresponds to the 
variable address, then this is a source where the content of the control unit variables is 
modified. 

The manner in which the program code is modified at the source depends on the particular 
type of addressing of the control xmit variables. 

25 This is depicted in Figure 2, which shows control xmit program code 201 and software 

Amotion 202. Arrows 203 symbolize the method described here for determining the store 
instructions. Store instruction 204 of a variable access is shown in such a way that in the case 
of direct addressing, the memory destination of the store instmction is the RAM address, and 
in the case of indirect addressing, the content of the address register corresponds to the RAM 
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address, so the load instructions may then be determined. Arrows 205 represent the method 
described here for determining the load instructions. Load instmctions 206 are for loading the 
variable addresses, specifically the global variables. 

Modification of the program points (Figures 3 through 8) 

5 First, the load instruction sources and/or the store instruction sources are localized according 
to different types of addressing and then the control unit function in which the sources are 
located is determined for these sources, so that all the function calls in the entire program 
code may be accomplished through function calls of the newly created hook fimction(s), so 
that the original function call of the control unit function may take place within the 
10 corresponding hook function. 

Modification of the load/store instructions 

With the microcontroller(s) described here, there are a number of different types of 
addressing in a wide variety of embodiments. It is possible to minimize this variety. 

Four methods which largely cover possible combinations of a write access to global variables 
15 are presented below. Other methods of code analysis are conceivable such as relative 
addressing via previously occupied address registers. 

To do so. Figure 3 shows an overview of the different methods for modifying the load and/or 
store instructions. Store instructions st.x here mean: st.b = store byte, st.h = store half word 
and st.w = store word. The four methods illustrated in Figure 3 are explained in greater detail 
20 below. 

Modification of the program points according to method 1 is illustrated in greater detail in 
Figure 4. Method 1 involves, for example, a 16-bit store instmction and indirect addressing. 
Starting fi-om the position of the found store instruction, the points are traced back in the 
disassembled program code xmtil the particular load instructions are determined. The found 
25 load instructions are the deciding factor for this method. This method is used not only in 
problems with a mixed instruction set but also when for other reasons it is impossible to 
replace the store instruction with a jump instruction. 

In method 1 the determined load instructions, based on the subsequent store instruction, are 
replaced by address information of a pointer variable. This pointer variable is generated via a 
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development environment, in particular the DIJooks development environment. The address 
of the pointer variable is in a reserved free area of the memory means, the memory layout for 
variables. The modified load instructions address the same address register as the original 
instructions. The difference in the modified load instmctions is in the type of addressing of 
5 the address register and the address information. 

Figure 4 illustrates method 1 in a schematic diagram showing original program code 401 and 
modified program code 411. The control unit function, function aQ here, is formed by 402, 
406 and 417, 407. The instructions, i.e., instmction sequences, are shown in 402 and 417, 
respectively, and the actual functionality is shown in 406 and 407. This shows access axx% 

10 to an address register (e.g., aO through al 5 in the case of a 16-bit width) and access dxx% to a 
data register (e.g., dO through dl5 in the case of a 16-bit width). Let us now consider 
instructions movh.a and Id.a (load instructions) and st.x (store instmction) in 408, 409, 410, 
413, 414 and 415. In this example, movh.a and Id.a are shown as 32-bit instmctions (see 412 
and 403). Store instruction st.x is shown as a 16-bit instmction (see 405) and therefore is not 

15 replaceable with a 32-bit jump instmction in this example. As stated previously, this also 

applies to all other cases in which such a replacement is impossible or undesirable. The novel 
instmction code according to the present invention, i.e., program code 403, is now input into 
412 and the load instmctions are modified to pointer variable iB_PtrMsg_xxx (Ptr = pointer). 
The address of the control unit variable is replaced by the address of the pointer variable 

20 according to 404. The method of creating additional program code, i.e., additional functions, 
is explained in greater detail below according to the four methods. 

Figure 5 shows in greater detail the modification of the program points according to method 
2. The same notations and abbreviations as used in method 1 are also applicable here as well 
as in all other method examples. Original program code 501 and modified program code 511 

25 are shown. The control imit function, function_aO here, is formed by 502, 506 and 517, 507. 
Instmctions and/or instmction sequences are shown in 502 and 517, and the actual 
functionality is shown in 506 and 507. Access %axx to an address register (e.g., aO through 
al5 in the case of a 16-bit width) and access %dxx to a data register (e.g., dO through dl5 in 
the case of a 16-bit width) are shown. Let us now consider instmctions movh.a and Id.a (load 

30 instmctions) and st.x (store instmction). Store instmction st.x is now shown as a 32-bit 

instmction (see 505) and is thus replaceable in this example by a 32-bit jump instmction j la. 
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The novel instruction code according to the present invention, i.e., program code 503 (jla: 
jump instruction), is now input into 505. 

Method 2 is a 32-bit store instruction in conjunction with indirect addressing. The 32-bit store 
instruction is replaced by an absolute jump instruction jla 512 to a software balcony function 
5 (balcony_M2) (see call 520 of the software balcony function). With the jla jump instruction, 
the jiunp back address is stored in register al 1 (see 521). 

In software balcony function 521 mentioned above, the content of address register %axx, by 
which the control unit variable is addressed, is replaced by the address value of a pointer 
variable (iB_PtrMsg_xxx). The index of address register %axx and of the previously loaded 
10 data register %dxx is identical in software balcony function 521 . 

When 32-bit store instructions are used for the software breakpoint, additional program code 
is required for this. This program code, generated in the DHooks development environment, 
is referred to as a balcony fiinction. The balcony fimctions include additional initializing, 
copying and breakpoint mechanisms and are used as software fimctions to expand the 
15 breakpoint functionality. Balcony functions are used for breakpoint methods 2, 3 and 4. 

The content of data register %dxx which is used remains unchanged by jump instruction jla. 
Addressing is then performed via the pointer in the software balcony fimction and thus the 
store instruction is diverted to the pointer variable. Store instruction st.x writes data as in the 
original code. 

20 The sequence then jvmips back into control unit fimction according to 522 via the jump back 
address stored in address register al 1 via an indirect jump. 

Figure 6 shows in greater detail the modification of the program points according to method 
3. The same notations and abbreviations are used here specifically as for method 2 and for all 
other method examples. Original program code 601 and modified program code 61 1 are 
25 shown. The control unit function, fiinction_aO here, is formed by 602, 607 and 617, 607. The 
instructions, i.e., instruction sequences, are shown in 602 and 617, respectively, and the 
actual functionality is shown in 606 and 607. A special st.x (store instruction), namely st.t, is 
considered. Store instmction st.t is now depicted as a 32-bit instruction (see 605) and thus is 
replaceable in this example by a 32-bit fimction call (call balcony_M3). The novel instmction 
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code according to the present invention, i.e., program code 603 (call: function call), is now 
input into 605. 

In method 3 a 32-bit store instruction st.t is used in combination with direct addressing 618 
(store instruction having address 610). The 32-bit store instruction is replaced by a 32-bit 
5 function call (call balcony_M3, 603) of a software balcony function (balcony_M3, 621) (see 
604). Software balcony function 621 includes the query of a breakpoint and the store 
instruction in the original state. With an activated breakpoint, no store instruction is executed. 
This variable is thus xmcoupled from the control unit function. To do so, call 620 for balcony 
function 621 is carried out from 612. Jump back 622 to the control unit function takes place 
10 via the address of the control imit variable (adr. of ecu variable) 619. 

Figure 7 shows the modification of the program points according to method 4 in more detail. 
As is the case with all other method examples, the same reference notations and abbreviations 
are used here, specifically the same as those used for method 2. Original program code 701 
and modified program code 71 1 are shown. The control unit function, function aQ here, is 

15 formed by 702, 706 and 717, 707. The instmctions, i.e., instruction sequences, are shown in 
702 and 717, respectively, and the actual functionality is shown in 706 and 707. Access %axx 
to an address register and access %dxx and/or %dyy to a data register are shown. Instructions 
mov, st.x (store instmction) call and j la shall now be considered as described above in the 
methods. Store instruction st.x is shown as a 32-bit instruction (see 705) and is thus 

20 replaceable in this example by a 32-bit jump instruction. The novel instruction code 

according to the present invention, i.e., program code 703 (jla: jimip instruction), is now input 
into 705. 

Method 4 uses a 32-bit store instruction st.x (710) in combination with direct addressing 
(718). The 32-bit store instruction is replaced by a 32-bit jump instruction jla (jla 

25 balcony_M4_a). The jump instruction points to software balcony function 1 

(balcony_M4 aO, 721) which is called with 720. In software balcony function 1 721, the 
content of the previously loaded data register %dxx is stored temporarily in a temporary 
DHook variable (iB_TmpMsg_xxx). Another balcony function (balcony_M4_bO, 724) is 
called from 721 with 723 via a function "call." This second software balcony function 2 

30 contains the actual breakpoint as in method 3. Software balcony function 724 contains the 
query of the breakpoint. When the breakpoint is deactivated, the content of temporary 
variable iB_TmpMsg_xxx is written back into the control imit variable (see 725). When the 
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breakpoint is active, there is no rewriting. The .control unit variable is thus uncoupled from 
the control unit function. The jump back to the control unit function then takes place via /22. 

Modification of function calls (Figure 8) 

For the localized load/store sources, the control unit function in which the sources are located 
5 is determined. This is done using the Windows software program developed for this method; 
on the basis of the position of the load/store instructions and with the help of reference 
information, it determines the corresponding beginning and end addresses of the control unit 
function. 

Next, all function calls of the control unit function in the entire program code are replaced by 
10 function calls of the newly created hook function. 

The original function call of the control unit function is performed within the corresponding 
hook function. 

For reasons of simplicity. Figure 8 uses the same diagram as that in the previous Figures 2, 4, 
5, 6 and 7 to make this illustration of the modification comparable. Original control unit 

1 5 program code 801 and modified program code 811 are shown. A task list task_list is used and 
a corresponding extra function or subfunction subfunction_xO is used. For the sake of 
simplicity, there is no longer an explicit differentiation between instruction sequence and 
actual functionality (see Figures 3 through 7). The procedure 804 according to Figure 2 is 
used to determine the function addresses and function calls. According to 805, the address of 

20 function a is replaced by the address of hook_function_a. Accordingly, at 806 the function 
call of function a is replaced by the call of hook_function_a. Finally, in 807, the indirect 
function call of function a is replaced by a call of hook function a (as a 32-bit instruction 
here). The newly formed program code with the replacements is indicated by nP. 

Method for creating additional program code (Figure 9) 

25 For each control unit function in which there is a breakpoint, a hook function may thus be 
created and/or is created. Figure 9 shows a schematic diagram of such hook functions, 
hook_function_aO and hook_function_xO. Control unit program code 901 and memory area 
902 for additional program code are shown. Actual hook functions 903 and possible 
initialization 904 of any pointer variable needed are also shown. Program code 905 is for the 
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software breakpoints, the configuration and tie-in of the rapid prototyping methods in 
particular. Finally, call 906 of original control unit function function_aO is shown. This is 
comparable for second hook function hook_function_xO but is not shown again for reasons 
of simplicity. 

5 The hook function thus includes the breakpoint mechanism which controls access to a rapid 
prototyping method via application data. In addition, initialization of pointer variables and 
function call of the actual control unit function are performed in the hook function if 
necessary. 

Features of the hook functions are described below as a function of the breakpoint methods. 

10 Re breakpoint methods 1 and 2: 

Before a store instruction to a control unit variable addressed by a pointer may be described 
appropriately, the pointer variable must be addressed using a variable address. The pointer is 
initialized in the hook function. If the breakpoint access is not active, the pointer is initialized 
using the address of the control unit variable. If the breakpoint access is active, the pointer is 

15 initialized using the address of a temporary DHooks variable. At this point, write access is 
diverted to the temporary variable, e.g., in the case of indirect addressing of the control xmit 
variable. 

Re breakpoint methods 3 and 4: 

These two methods involve direct addressing of a control unit variable. No pointers which 
20 must be initialized are used here. The hook function includes the mechanism for controlling 
the software breakpoint and the function call of the original control xmit function. 

At this point, the balcony function when replaced by a jump instmction as already explained 
above should be mentioned briefly. This use was explained above in detail. If 32-bit store 
instructions are used for the software breakpoint, then additional program code is required for 
25 this purpose. This program code is generated in the DHooks development environment and is 
referred to as a balloon function. Balloon functions include additional initialization, copying 
and breakpoint mechanisms and are used as software functions to expand the breakpoint 
functionality. Balcony functions are used for breakpoint methods 2, 3 and 4. 

Segmenting the memory areas (Figure 10) 
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Dedicated memory areas of the memory means in memory layout SI of the control unit 
software program are needed for the breakpoint method. According to Figure 10, the method 
shows free areas for code (DHook code) S4, data (DHook data) S3 and RAM (DHook-RAM) 
S2. The breakpoint functions (additional program codes) are stored in the code area, and 
application variables by which the breakpoint mechanism is controlled are stored in the data 
area. The pointer variables and administrative RAM variables needed for the method are 
stored in the free area for RAM variables. 

Development process for creating the program code (Figure 1 1) 

The software breakpoint code is generated automatically via a development environment 
created for the method and is illustrated again in Figure 11. The variables in point 8 may also 
be selected automatically according to specifiable criteria. 

1. Hex code file (includes the machine code, e.g., in Intel hex or Motorola SI 9 format) 

2. Application data description file (includes, for example, addresses and conversion 
formulas for variables and parameters) 

3. ELF binary file (linker output file having addresses of ftmctions and variables) 

4. Program for converting machine code into readable assembler instructions 

5. Disassembled program code (used as input for the simulator) 

6. Converter for providing program information 

7. Reference databank (used to resolve open references) 

8. User creates selection of variables for breakpoints 

9. Information about control unit variables to be bypassed 

10. Program code simulator (reads all opcodes sequentially and checks the register 
contents) 

11. Automatically generated source code (includes the program code for the software 
breakpoints, additional fiinctions and infomiation about the program code points to be 
modified) 
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12. 



Software development environment (cpntrols all procedures for generating hex code 
and the apphcation data) 



13. Apphcation data for controlling the breakpoints 

14. Program code + breakpoint code + patch code 

5 15. Hex/A21 merge procedure (dynamic hooks components are connected to the original 
program code) 

16. Application data description file (includes the project application data and the 
breakpoint application data) 

17. Program version having soflware breakpoints 

10 Method for tying in the software breakpoint code 

The software breakpoint code is tied in, by a hex-code merge run, for example In this action, 
the results (hex codes) of the development environment for the dynamic breakpoint method 
are copied into free areas of the original software program (hex code). The method has a 
structure similar to that of the internal control unit bypass in which hex code information 
15 from two separate software development runs is joined together. 

Intemal bypass (Figure 12) 

Coupling of the bypass program which includes at least one bypass fimction is performed by 
dynamic linking to predetermined interfaces in the control program. In this way, it is possible 
to access data present in the electronic computer unit during the program sequence of the 
20 control program. 

Figure 12 illustrates the dynamic linking of the bypass fimctions. A first block 60 reflects the 
vector table available to the control program. This figure shows a first column (vector) 62 and 
a second colimrn (channel) 64. The first column 62 contains references on the basis of which 
a decision is made as to which bypass function is to be activated. The second colxmm 64 
25 contains information about whether it is an intemal or external bypass. 

A second block 66 gives a table of function pointers containing a number of bypass functions 
to be activated. 
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A third block 68 represents bypass services. A. fourth block 70 and a fifth block 72 stand for 
activated bypass fiinctions and a sixth block 74 stands for the control program. 

Potential intervention points for the bypass functions are provided in control program 74. 
This is accomplished by activating a driver layer (bypass services). 

Before checking control program 74, the application system loads the bypass functions into 
the memory of the ECU. References to the bypass functions are then entered by the 
application system into table 66 of the function pointers. 

During the check, i.e., during the sequence of control program 74, bypass services 68 in the 
ECU decide on the basis of entries in vector table 60 which intervention is active, i.e., which 
bypass function must be activated and where the reference to the bypass function is stored, as 
indicated by arrows 76. 

If a bypass function for a potential intervention point has been activated, it is retrieved via the 
reference (dynamic link), represented by arrows 78. Bypass services 68 execute the two 
active bypass functions 70 and 72 (arrow 80). With activated bypass functions 70 and 72, 
certain selected data 82 in control program 74 is accessed, as indicated by arrows 84. 

In data transmission to bypass functions 70 and 72, the latter access their input variables and 
parameters (application values) via address references. Bypass functions 70 and 72 thus have 
read access to all data 82 statically present in the ECU. 

The bypass drivers receive a reference to the stimulatable data flow in the data transmission 
of the control program, i.e., user software 74. In this way the data consistency requirements 
may be met. 

The calculations of the bypass and the intervention into the data flow take place at the point 
in time when the value is also being calculated in the basic software. Due to the application of 
these trigger mechanisms and the commimication described above, there is no dead time in 
the signal flow of the bypass function. 

Software test bv stimulation of functions 

The present invention relates to a software test method with which test sequences are 
generated according to the user's specifications in a test environment by using the methods of 
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dynamic hooks (automatic software breakpoint) and internal bypass (rapid prototyping 
method) and these test sequences are run within the control imit software. Using the dynamic 
hooks software breakpoint method, the input variables of the corresponding control unit 
fimctions are bypassed. The test description, i.e., the test sequence over time, is generated in a 
5 program writing language developed for the method within the development environment 
created for the method. The source code thereby generated, describing the test sequence, is 
translated via a compiler and linking procedure into a runnable software program for the 
target hardware (control unit). The test sequence code is integrated and executed according to 
the internal bypass method. 

10 Stimulation of software fimctions within a runtime svstem CFigure 13) 

hi investigating a control unit fimction, the corresponding input quantities (RAM vetriables) 
of the software fimction are bypassed. The bypassed RAM variables are stimulated via the 
integrated test sequence program in the control unit software. Scheduling for the call of the 
test sequence code may be specified in the development environment. The bypassed RAM 
1 5 variables are accessed via references. 

Figure 13 schematically shows such a stimulation. A corresponding control imit fimction(s) 
91 is(are) shown. Literface variables, i.e., input variables 92 (inpl, inp2, inp3) which are 
calculated in other fimctions, i.e., software fimctions, for example, and are available as global 
variables in the system, are also shown. Three of the software brea]q)oints 93 already 
20 mentioned that are expediently activated via the application system (in particular 101 in 
Figure 1) are also shown. 

Stimulation values 95 (inpls, inp2s, inp3s) and/or their data information are available firom 
the test sequence software, i.e., stimulation fimctions 94, as a replacement within the context 
of the breakpoint for the interface variables, i.e., input variables 92, and are blended in on 
25 activation of the breakpoints. 

Finally, the control unit software 96 itself is shown. 

Method for creating test sequence software (Figure 14) 

The test sequence is specified in a test description language developed for the method. Li this 
test sequence, the input variables of the control unit fimction are brought to defined states. 
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Various combinations of stimuli values^ ramps, or curves may be specified. The behavior over 
time is controlled via corresponding software fimctions within the description language. 
Figure 14 shows an example of such a test sequence description. 

Figure 15 shows the development process as the object of the present invention: 

5 El identifies the control unit software. E2 shows the test fimction and information about the 
interface variables. This also includes the scope of testing and the interface information on 
the software fiinction or fimction to be tested or stimulated. E3 shows the bypass selection, 
i.e., the selection of bypass variables, and thus the soflrware extent of the bypass. The 
dynamic hooks method is localized in E4 as described previously. The program version 
10 having bypassed input variables of the software function to be tested or stimulated, i.e., the 
control unit program having the software breakpoints, is accommodated in E5. 

In E6 the test sequence script is created, i.e., processed; this is the test description of the test 
sequence using a script language. Code translatable fi*om the test script(s), in particular C 
code, is created by converter, i.e., code generator, in E7. This generated code, i.e., the test 
15 sequence program code, is depicted in E8. Library fimctions in a library (LIB) for sequence 
control are shown in E9. 

ElO shows the software test development environment for program code creation, i.e., the 
hex codes and application data. ElO also includes the compiler/linker tool set so that finally 
the software for the test sequence in the control unit is generated in ElO. A distinction is 
20 made here between Ell, the application data (A2L) for controlling the test sequence and the 
accesses to variables, and El 2, the program code and test sequence code, i.e., the actual test 
sequence software (HEX). 

The merge procedure (A21-HEX merge procedure) takes place in El 3 to generate the project 
software, having integrated software breakpoints, and the test sequence code. 

25 Finally, this results in the control unit program having the integrated software test sequence. 
E14 contains the application data description file having the project data, i.e., breakpoint data 
and the application data for the test sequence control. El 5 also contains the finished program 
version having the software breakpoints and the test sequence code. 
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It is thus possible according to the present invention through an integrated software test 
method and the corresponding device to test software fiinctions, i.e., functions for control of 
operating sequences, in particular in a motor vehicle, within a control imit system during 
runtime by stimulation of their input variables via corresponding software interventions, i.e., 
5 software breakpoints under various operating points. 
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